Removed this because it gets out of sync very quickly as the code evolves.

We could replace the reference to specific instances with a search query like https://github.com/search?q=repo%3AWordPress%2Fgutenberg+commandsStore+language%3AJavaScript&type=code&l=JavaScript which should always return relevant results.

I hate this selector, it's so bad in so many ways, but it's what we have today. Let's keep changes to that for later.

Just curious, how do you think it could be improved?

• Well first it says getTemplateInfo and it works both for templates and template parts
• I don't see why we need something like that specific to these post types but can't include all post types (to avoid the isTemplate conditionals in this component for instance)
• It takes an object, why? It should take postType, postId. A selector taking an object like that is hard to memoize... The object is probably changing way too often.
• It is also misplaced, I'm not sure why this is the "editor" package, it should be something for "core-data" maybe.

We could replace the reference to specific instances with a search query like https://github.com/search?q=repo%3AWordPress%2Fgutenberg+commandsStore+language%3AJavaScript&type=code&l=JavaScript which should always return relevant results.

Just curious, how do you think it could be improved?

I know it's already like this in the site editor, but this absolutely positioned button makes the focus ring for the command palette button take up the whole bar:

which is a bit confusing because it doesn't correspond to the effective clickable area.

Yes, that's a design question that I'll leave out of this PR, the problem is that we also want to change the whole color on hover.

Why memo? It's just a string?

Bad habit. Thanks for noticing

Why is this limited only to template types? Navigation Menu posts (wp_navigation) are also edited in this context and it seems like "back" default rendering mode would be useful here also. I'm just checking whether this was intentionally locked down to templates only.

Oh I see, this is about rendering modes.

How would you feel about the default "back" action always be to go "back" in the @wordpress/router history?

eg. history.back()

Design would like this "Back" button to become the default way to go back out of the template editing mode and I need to implement this in #55657.

The post editor doesn't use the router, so this would break.

I also feel like "back" using "history.back" is a bit redundant with the browser's back button. This "back" is more a "exist template mode" button.

Thanks for going over this again Joen. So hopefully we can agree that UI-wise we'd like the "Back" in the top toolbar to become the default UI control for that action?

@youknowriad Technically, could we add a referrer prop to the URL which we can then consume to determine the best location for "back". If none is provided we optimise for "go back to the main site editor view"?

Obviously there would need to be an exception for situations like what is currently handled in this PR where "Back" means "Exit template editing mode" but that's simple enough. What do you think?

To be honest, it's not satisfying for me. I think we're breaking a big conceptual element in order to satisfy a small affordance.

Think of the whole editor or frame as <Editor postType={ currentPostType } postId={ currentPostId } />. So the whole editor is just a "reusable component" that you can use in any context (post editor, site editor, elsewhere...).

Also the editor understands "template modes" so you can do <Editor postType={postType} postId={postId} templateId={templateId} /> and all the switching of modes (from post+template to template only and back...) is all internal. So in that sense, a "back" button within the editor to switch between these modes make sense.

Now, think of focus modes: focus modes mean switching the actual "postType" and "postId" passed to the editor, so they are things that are external to the editor. It's a shame to have to update the editor internally for this affordance. Also and more imporantly, it might not make sense in all these "editors" and "frames". For me, "focus mode" means navigating to another entity in the site editor, you actually switch a lot of things, not just the UI of the editor, you switch the active page in the sidebar of the site editor, you switch the URL..., you're not within the same editor anymore, it's another one. So it feels weird to have a back button within the editor. For me it's a cross page affordance and in that sense is better placed outside the editor.

Now, that is my opinion and my strong opinion here is that we shouldn't break the Editor abstraction just for this. That said, If you all feel very strongly about this "back" button, we can try to find a compromise and have a "setting" in the settings passed to EditorProvider that contains the "back referrer" or something like that. Maybe even make it a private setting (private API)

But I persist, that I think it's wrong personally :)

Can we agree that when users enter focus mode for a template part they need to be given an easy way back to the template they were editing?

better placed outside the editor

Do you mean literally? The idea of a notice bar at the bottom of the viewport has come up a few times but never really gained much traction.

Worth noting theres a 'Back to x' suggestion in the command palette when you click the document bar, so I'd agree with Joen – the current placement feels natural in terms of UX.

After discussing more with @jasmussen It seems the main point of friction is that:

• we have "focus mode" for template part, navigation block and things like that where in fact we actually navigate to another page of the site editor.
• we have "template mode" in the site editor where we show a template, but we don't call that "focus mode" and we don't navigate to another page of the site editor.

If we are to treat the "back" button as similar for both these cases, they should first work similarly. In other words, maybe the "template mode" should be removed and instead we should navigate to the "template page" of the site editor instead.

Also, if we do that, and since the "template mode" is also an affordance of the "post editor", we should make sure to also add some kind of "template page" to the post editor too (maybe no url navigation there or anything but at least it should be something in the "state" of the post editor and the post editor should be able to switch).